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Amendments to the Specification; 
Please add the following new paragr^hs after paragraph [0090]: 
[0090.1] H.324 SRP Extension 

[0090,2] There is also scope to optimize IL324 SRP to support fester call setup, call tear- 
down and other session messaging (H>24S Messaging), in environments where network latency 
is significant. One of the features of H.324/IL245 is the use of SRP, which provides 
acknowledgement for all delivered PDUs. This is useful to ensure that all command and control 
messages have been received at the £ar end temiinal, but provides a limit to the throughput of 
messages on networks with moderate to hi^ latency (>4Qms round trip thne). 

[0090J] SRP only allows for one message to be outstanding at any time to ensure 
guaranteed delivery and correct message sequencing. This latency can be mitigated to some 
extent by minimizing the number of messages exchanged during call setup such as a message 
containing mtiltiple Multiplex Table Entries, or combining Tenninal Capability Set and Master 
Slave det^mination messages, however it does still adversely impact the can setiqp time. 

[0090.4] In addition timeouts are such witiiia H324/H.245 that if a critical packet (or its 
acknowledgement) is lost during call setup (perhsqps due to data loss) the call may fail, and abort 
if timer values within stack implementations are not tuned appropriately* 

[0090,5] All of these phases are necessary to remain standards compliant, but it may be the 
case that in some circumstances SRP may be used in such a way to allow messages to be sent 
while an SRP ACK is outstanding. 

[0090.6] In many cases the H.324/H.24S procedures are artificially held back due to tiie 
behavior of H.245/SRP* Essentially independent procedures such as the opening of different 
logical channels are unnecessarily coi:y)led by the req\iirement that only one H.245 SDU may be 
outstanding at any time. By removing this limitation for independent procedures it is estimated 
tiiat the time to execute H.245 procedures could be reduced by between 50-100%. 
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[0090.7] Some SDUs must be preserved m strict order, for example with all procedures, or 
within a single instance of an Open Logical Channel procedure, however independent OLC 
requests do not need to be coupled as they are in the current standard* 

[0090.8J In order to allow new SDUs to be transmitted while SRP ACKs are outstanding a 
means of identifying SRFs and associating them with the relevant message is required. One 
approach would be to use Numb^ed SRFs are required. The alternatives to Ms scheme are 
based on a Selective ACK, or a sliding window scheme, as described below. 

[0090.9] In order to minimize implementation complexity and maintain maximum 
consistency it is recommended that a sliding window scheme is used. This will allow the 
H.324/H.245 implementation to send a maximum of n SRP packets without corresponding ACKs 
being received. The H.24S implementation itself must maintain locking to ensure that only one 
SDU ACK is outstanding &om each state machine instance (typically per H.24S procedure), 
o&erwise message sequences within each state machine cannot be guaranteed 

[0090*10] In order to enable this behavior the H.324 entity must be able to signal to the far 
end that it is capable of handling this sch^e* It is suggested that this be included with Terminal 
Capability Set, as is the case with NSKP, but a alternative header field would be required to 
specify the remote hahdling of this case. In the case where the fast connect scheme described 
above is used this will have no impact on call setup time, however it will improve speed and 
reliability for subsequent H.24S control operations. 
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